With the rapid development of 3G, 4G and radio communication technologies, more and more people surf the Internet by using mobile terminals such as data cards and MIFI.
A page for setting is needed for a device such as a data card and MIFI usually, and is presented to a user in a form of a Web page (the Web page is hereinafter referred to as web_ui) usually, web_ui has a local domain name and a local area network Internet Protocol (IP) address (gateway address of terminal). When the device is connected to a Personal Computer (PC), the user may open web_ui of the device by inputting the local domain name or gateway IP address into a PC browser, and may perform relevant operation and setting on the device.
Generally speaking, the user will not open web_ui. Under some conditions, when the user opens a web page by using the browser, a terminal needs to actively assist the user in redirection to a Web page of a gateway to give relevant prompts, thus improving the user experience. If the device is not networked, the user cannot browse a web page via the device, it is necessary to redirect to web_ui, and the user is prompted to operate the device to be networked. After online upgrade is completed, it is necessary to redirect to web_ui, and the user is prompted of a scenario such as an upgrade result.
At current, mainly two solutions for redirecting a device to web_ui are used.
Solution 1: A Domain Name System (DNS) request data packet sent from a PC is captured, and when a redirection condition is satisfied, a DNS response packet of which a domain name resolution result is a gateway address is assembled and returned to the PC.
Solution 2: A tcp data packet sent from a PC is captured, when a redirection condition is satisfied, a tcp message is routed to a Web server of a gateway, and when browser tcp handshaking is completed and an http request is successfully sent out, a response packet of which http 302 is redirected to a web_ui domain name is assembled and returned to the PC, thus achieving the aim of redirecting to web_ui. In the solution, when the device is not networked, a DNS module is also needed to return a fixed virtual IP address response, such that a PC browser completes DNS resolution, and smoothly sends out a tcp handshaking message.
Both the solutions have the defects of user experience resulting from optimization of the PC browser: when accessing a domain name and conducting DNS resolution successfully, in order to improve the web page access efficiency, the PC browser will save a correspondence between the domain name and an IP address obtained by DNS resolution in browser caching for a period of time. When the caching is effective and the domain name is re-accessed in the same label page, DNS resolution is jumped, and access is conducted by directly using the saved IP address. As for solution 1, when the redirection condition is satisfied, a DNS response for the gateway address is given to the PC for redirection, the PC browser saves this DNS resolution result, and if the device does not need to be redirected within the period of effective time for browser caching and the user continues accessing the domain name in the same label page of the browser, the browser jumps a DNS resolution stage, accesses by directly using the gateway address, and redirects to web_ui again until the caching fails or the user re-opens a label page. Similarly, as for solution 2, a redirected domain name when the device is not networked also has this defect.
Any effective solution has not been proposed yet currently for the problem in the related art where a redirected domain name will be redirected within a period of time in case of not wiping a cache from a PC browser when being not required to be redirected due to optimization of the PC browser.